2008 24.05.(Sa) 20:15:54  <txwikinger> Mein Name ist Ralph Janke und ich bin Diplom-Informatiker
2008 24.05.(Sa) 20:16:22  <txwikinger> Ich habe ausserdem ein Masters in Informatik und ein Bachelor in Englischen Jura
2008 24.05.(Sa) 20:16:59  <txwikinger> Weiterhin bin ich ein Ubuntu-Member und Maintainer von ein paar Software-Paketen in Debian und (K)Ubuntu
2008 24.05.(Sa) 20:17:34  <txwikinger> Das Thema heute ist: Wie schreibt man gute Fehlerberichte in Launchpad?
2008 24.05.(Sa) 20:17:53  <txwikinger> Wenn jemand Fragen hat, bitte mit ! melden, ich rufe dann auf
2008 24.05.(Sa) 20:18:10  <txwikinger> die Frage dann bitte mit # abschliessen.... alles klar?
2008 24.05.(Sa) 20:18:44  <dee> ja. :)
2008 24.05.(Sa) 20:18:51  <txwikinger> ok... Wie schreibt man gute Fehlerberichte in Launchpad?
2008 24.05.(Sa) 20:19:01  <txwikinger> Um diese Frage kompetent zu beantworten, müssen wir uns erst einmal überlegen, wozu Fehlerberichte eigentlich geschrieben werden, und wofür Fehlerberichte nicht geschrieben werden sollten.
2008 24.05.(Sa) 20:19:20  <txwikinger> Der grundsätzliche Grund für Fehlerberichte, ist der, dass man Software verbessern möchte.
2008 24.05.(Sa) 20:19:39  <txwikinger> Software ist selten fehlerfrei. Und es ist unmöglich Software 100% zu testen (validieren).
2008 24.05.(Sa) 20:19:57  <txwikinger> Selbst mit automatischen Validierungssystemen wird nur eine beschränkte Anzahl von Testfällen getestet oder Codedurchläufe durchgegangen.
2008 24.05.(Sa) 20:20:22  <txwikinger> Das ganze wird noch komplizierter, wenn man Interaktionen zwischen verschiedenen Softwarepaketen und verschiedene Platformen in Betracht zieht.
2008 24.05.(Sa) 20:20:50  <txwikinger> Also müssen wir es in Kauf nehmen, dass Software veröffentlicht wird, die nicht fehlerfrei ist.
2008 24.05.(Sa) 20:21:07  <txwikinger> Im Grunde ist dies sogar das Manta von Freier Software (Veröffentliche früh, veröffentliche oft).
2008 24.05.(Sa) 20:21:32  <txwikinger> Also müssen wir einen Kommunikationskanal bereitstellen, der die notwendige Information über Softwarefehler vom Benutzer zurück zum Entwickler erziehlt.
2008 24.05.(Sa) 20:22:00  <txwikinger> Diesen Kommunikationskanal stellen Bugtracker, die eine Sammlung von Fehlerberichten sind dar.
2008 24.05.(Sa) 20:22:18  <txwikinger> Also ist die einzige und grundsätzliche Aufgabe von Fehlerberichten die angesprochene Informationsübermittlung.
2008 24.05.(Sa) 20:22:33  <txwikinger> Dies zeigt auch schon in gewisserweise auf, was Fehlerberichte nicht sind.
2008 24.05.(Sa) 20:22:48  <txwikinger> Generelle Beschwerden oder Meinungen, dass die Software nicht gut ist, helfen nicht.
2008 24.05.(Sa) 20:22:59  <txwikinger> Jegliche Emotionen (vorallem negative) helfen nicht.
2008 24.05.(Sa) 20:23:12  <txwikinger> Fragen wie man Software benutzt, helfen nicht der Fehlerbereinigung.
2008 24.05.(Sa) 20:23:24  <txwikinger> Fragen sollten in anderen Foren gebracht werden. Dafür gibt es IRC-Kanäle, Foren, und den Launchpad-Answertracker.
2008 24.05.(Sa) 20:23:54  <txwikinger> Also Fehlerberichte sollten sich darauf beschränken Fehler in Software zu beschreiben und damit zu den Entwicklern zu übermittlen.
2008 24.05.(Sa) 20:24:14  <txwikinger> Ok.. soweit alles klar?
2008 24.05.(Sa) 20:24:24  <dee> *nick*
2008 24.05.(Sa) 20:24:30  <txwikinger> Gut... Nachdem wir jetzt dargestellt haben, was Fehlerberichte sind, sollten wir darüber nachdenken, was sie enthalten sollten.
2008 24.05.(Sa) 20:24:45  <\sh> ! Ich dachte software developer denken immer software ist fehlerfrei und der benutzer ist der fehler?! ;)
2008 24.05.(Sa) 20:25:03  <\sh> #
2008 24.05.(Sa) 20:25:15  <txwikinger> Ja \sh... ich habe von solchen Entwicklern gehört :)
2008 24.05.(Sa) 20:25:56  <txwikinger> Meistens haben die ein überzogenes Selbstbewusstsein und die Software ist nicht sehr gut ;)
2008 24.05.(Sa) 20:26:18  <txwikinger> Ein wichtiger Grundsatz ist, dass jeder Fehler in einem gesonderten Bericht beschrieben werden soll.
2008 24.05.(Sa) 20:26:18  <\sh> ! ein sogenanntes layer 8 und manchmal layer 9 problem ... aber weiter#
2008 24.05.(Sa) 20:26:32  <pedroc> hi, wie kann ich eine fish-session in konqueror beenden? einfach nur knoqueror schließen hilft nicht
2008 24.05.(Sa) 20:26:56  <\sh> pedroc, Technische Hilfe gibt es in #kubuntu-de
2008 24.05.(Sa) 20:27:12  <-- milian (n=milian@p4FC1072D.dip0.t-ipconnect.de) hat das IRC verlassen (Read error: 104 (Connection reset by peer))
2008 24.05.(Sa) 20:27:14  <txwikinger> ok... zurück zum Thema
2008 24.05.(Sa) 20:27:16  <txwikinger> Ein wichtiger Grundsatz ist, dass jeder Fehler in einem gesonderten Bericht beschrieben werden soll.
2008 24.05.(Sa) 20:27:26  <txwikinger> Dies hilft bei der Nachverfolgung der Fehlerberichte durch den Bereinigungsprozess.
2008 24.05.(Sa) 20:27:44  <txwikinger> Es ist sehr problematisch für den Prozess wenn mehrere Probleme in einem Fehlerbericht zusammengefasst werden.
2008 24.05.(Sa) 20:27:54  <pedroc> dort bekomme ich keine antwort
2008 24.05.(Sa) 20:28:14  <txwikinger> pedroc: Wir haben hier gerade ein Tutorial
2008 24.05.(Sa) 20:28:28  <pedroc> ok
2008 24.05.(Sa) 20:28:41  <txwikinger> Grundsätzlich ist es auch ideal, wenn ein Fehler reproduzierbar ist.
2008 24.05.(Sa) 20:28:54  <txwikinger> Das bedeutet ein Entwickler oder Tester hat alle Informationen wie man den Fehler provozieren kann.
2008 24.05.(Sa) 20:29:08  <txwikinger> Dies erlaubt dann das sogenannte debugging, also das Schritt-für-Schritt Nachverfolgen, warum der Fehler passiert.
2008 24.05.(Sa) 20:29:27  <txwikinger> Um dies zu erlauben, sollte man so gut wie möglich beschreiben, was man machen muss, um den Softwarefehler zu reproduzieren.
2008 24.05.(Sa) 20:29:43  <txwikinger> Also eine Schritt-für-Schritt Beschreibung, die es jeder beliebigen Person erlaubt den Fehler nachzuvollziehen, ohne dass irgendwelche Zwischenschritte erraten werden müssen.
2008 24.05.(Sa) 20:30:31  <txwikinger> Am Besten sollte dies auch eine Person tuen können, die das entsprechende Softwarepaket nicht als Experte kennt, da oftmals Nichtentwickler die Fehlerberichte für die Entwickler vorsortieren und auf Vollständigkeit prüfen.
2008 24.05.(Sa) 20:30:34  <txwikinger> Dies ist eines der grössten Probleme bei Fehlerberichten.
2008 24.05.(Sa) 20:30:43  <txwikinger> Oftmals enthalten sie keinerlei Beschreibungen wie man den Fehler provoziert.
2008 24.05.(Sa) 20:30:55  <txwikinger> Dies bedeutet, dass Tester und Entwickler oft Zeit damit vergeuden dies selbst herauszufinden.
2008 24.05.(Sa) 20:31:19  <txwikinger> Natürlich gibt es auch Situationen, in denen es dem Benutzer unmöglich ist, die Schritte genau zu beschreiben, weil der Fehler noch nicht einmal auf dem Rechner des Benutzers einwandfrei zu reproduzieren ist.
2008 24.05.(Sa) 20:31:40  <txwikinger> Aber dann sollte man dies auch als Information mitgeben, und so gut wie möglich beschreiben was man gemacht hat.
2008 24.05.(Sa) 20:32:01  <txwikinger> Vorallem wenn stack traces oder crash-Dateien mitgibt, können Entwickler oftmals noch genügend Informationen herausfiltern, die es erlauben Fehler zu bereinigen.
2008 24.05.(Sa) 20:32:29  <txwikinger> Allerdings ist dies natürlich schwieriger als wenn man Fehler einwandfrei reproduzieren kann.
2008 24.05.(Sa) 20:32:49  <txwikinger> Weiterhin ist es hilfreich soviel Information wie möglich über die Umgebung zu geben.
2008 24.05.(Sa) 20:33:07  <txwikinger> Also, welche Ubuntu-Version, welche Benutzeroberfläche, die Versionsnummern der Pakete die vielleicht einen Einfluss haben, die Architektur, usw.
2008 24.05.(Sa) 20:33:28  <txwikinger> Viele Fehlerberichte haben kaum Informationen darüber.
2008 24.05.(Sa) 20:33:42  <-- Glaubenskrieger_ (n=conv@i577AA871.versanet.de) hat das IRC verlassen ("Konversation terminated!")
2008 24.05.(Sa) 20:33:44  <txwikinger> Dies macht es dann sehr schwierig Fehler zu reporduzieren, da es schwierig ist festzustellen, ob ein Fehler vielleicht in einer neueren Version vielleicht bereinigt ist, oder eine Interaktion zwischen verschiedenen Softwarepaketen das Problem auslöst.
2008 24.05.(Sa) 20:34:01  <txwikinger> Also, auch hier, umso mehr Information beigefügt wird, umso besser.
2008 24.05.(Sa) 20:34:15  <txwikinger> Natürlich kann es auch sein, dass zuviel unnötige Information beigefügt wird, oder die Information unübersichtlich ist.
2008 24.05.(Sa) 20:34:38  <txwikinger> Daher ist es wichtig immer zu überlegen welche Information einem Entwickler hilft, und in welcher Weise sie am Besten einem Entwickler präsentiert wird.
2008 24.05.(Sa) 20:35:02  <txwikinger> Es kommt auch sehr darauf an, was für einen Fehler beschrieben wird.
2008 24.05.(Sa) 20:35:18  <dee> !
2008 24.05.(Sa) 20:35:43  <txwikinger> Oftmals kann ein Screenshot sehr hilfreich sein., wenn es sich zum Beispiel um eine Benutzeroberfläche handelt.
2008 24.05.(Sa) 20:35:48  <txwikinger> dee:
2008 24.05.(Sa) 20:35:50  <dee> In meinen Augen ist das eines der Probleme, die Normalbenutzer nicht immer entscheiden können. Also was wichtig ist und was nicht. Nur als Anmerkung. #
2008 24.05.(Sa) 20:36:08  <txwikinger> dee: Ja das ist richtig
2008 24.05.(Sa) 20:36:32  <txwikinger> Allerdings ist es immer gut sich diese Frage zu stellen wenn man einen Fehlerbericht schreibt
2008 24.05.(Sa) 20:36:59  <txwikinger> Perfektion ist hier weniger wichtig, als in die richtige Richtung zu gehen
2008 24.05.(Sa) 20:37:17  <txwikinger> Beantwortet das Deine Anmerkung?
2008 24.05.(Sa) 20:37:49  <\sh> !
2008 24.05.(Sa) 20:37:54  <txwikinger>  \sh:
2008 24.05.(Sa) 20:37:57  --> Glaubenskrieger (n=conv@i577AA871.versanet.de) ist in den Channel #kubuntu-de.org gekommen
2008 24.05.(Sa) 20:38:34  <\sh> dee: Wir, als Entwickler, wissen das, dass es fuer User sehr schwierig ist das zu Entscheiden, deswegen haben wir div. Tools in unseren Development Releases die dem User viel arbeit schon abnehmen
2008 24.05.(Sa) 20:39:04  <\sh> dee: Weiterhin, wenn infos fehlen, fragen bugtriager oder developer sehr oft nach weiteren infos, und schreiben auch wie man diese bekommen als normaler benutzer
2008 24.05.(Sa) 20:39:06  <\sh> #
2008 24.05.(Sa) 20:39:16  <txwikinger> Ja.. dass ist alles richtig
2008 24.05.(Sa) 20:39:44  <txwikinger> Aber das Thema hier ist ja wie man von vorneherein seine Fehlerberichte verbessern kann ;)
2008 24.05.(Sa) 20:40:29  <txwikinger> Dies geschieht im Zusatz zu den Tools wie apport und dem Bug-Triage Prozess, den ich im nächsten Vortrag beschreiben werde
2008 24.05.(Sa) 20:40:41  <txwikinger> Bevor man einen Fehlerbericht schreibt, sollte man nachforschen ob es schon einen Bericht über den Fehler gibt.
2008 24.05.(Sa) 20:41:07  <txwikinger> Ansonsten werden unnötige Duplikate produziert, dementsprechend Zeit und Resoursen verschwendet.
2008 24.05.(Sa) 20:41:25  <dee> txwikinger: sorry, ja. tat es. :)
2008 24.05.(Sa) 20:41:30  <txwikinger> Es kann hilfreich sein, in diesem Fall Informationen zu dem bestehenden Fehlerbericht hinzuzufügen, allerdings nur wenn es wirklich mehr Information ist.
2008 24.05.(Sa) 20:41:55  <txwikinger> Wenn ein Bericht schon bestätigt ist, sind weitere Kommentare wie "bei mir passiert das auch" nicht hilfreich.
2008 24.05.(Sa) 20:42:08  <txwikinger> Allerdings kann es sehr hilfreich sein, wenn die Information aufzeigt, dass der Fehler in der neusten Version immer noch auftritt, was vorher nicht klar war.
2008 24.05.(Sa) 20:42:25  <txwikinger> Es ist auch wichtig, dass Fehlerberichte nicht "entführt" werden.
2008 24.05.(Sa) 20:42:37  <txwikinger> Oftmals kommentieren Leute Probleme, die wirklich einen anderen Ursprung haben.
2008 24.05.(Sa) 20:42:51  <txwikinger> Dies führt dazu das die Bereinigung nicht nachvollziehrbar ist, oder der Versuch einen Fehler zu reproduzieren unnötig erschwert wird.
2008 24.05.(Sa) 20:43:03  <txwikinger> Solche Diskussionen können in Foren interessant sein, aber in Fehlerberichten stören sie.
2008 24.05.(Sa) 20:43:25  <txwikinger> Feature requests
2008 24.05.(Sa) 20:43:34  <txwikinger> Geringfügige Erweiterungswünsche für Software können in launchpad gegeben werden.
2008 24.05.(Sa) 20:43:47  <txwikinger> Diese sollte in einem Bereich sein, dass die Implementierung nicht dem Aufwand einer normalen Fehlerbereinigung übersteigt.
2008 24.05.(Sa) 20:44:02  <txwikinger> Allerdings sind hier Standardkonfigurationen ausgenommen.
2008 24.05.(Sa) 20:44:30  <txwikinger> Diese sollte eher in Foren, Mailinglisten oder in der neune Ubuntu Webseite Brainstorm (http://brainstorm.ubuntu.com) gemacht werden, damit sie diskutiert werden können
2008 24.05.(Sa) 20:44:30  <-- TheInfinitz (n=TheInfin@bchm-4d093bdf.pool.mediaWays.net) hat das IRC verlassen ()
2008 24.05.(Sa) 20:44:46  <txwikinger> Dies gilt auch für umfangreichere Erweiterungswünsche. Diese sollten auch in Blueprints registriert werden und auf der eigenen Wikiseite nach der veröffentlichen Schablone dargestellt werden.
2008 24.05.(Sa) 20:45:28  <txwikinger> Dies bringt eine letzte Frage:
2008 24.05.(Sa) 20:45:31  <txwikinger> Wo sollte man Fehlerberichte schreiben?
2008 24.05.(Sa) 20:45:42  <txwikinger> s gibt eine Menge Bugtrackers und es gibt hierfür zwei Gedankenrichtungen.
2008 24.05.(Sa) 20:45:45  <txwikinger> Es
2008 24.05.(Sa) 20:45:58  <txwikinger> Auf der einen Seite ist es gut die Fehlerberichte so nah wie möglich an die Quelle der Software zu plazieren.
2008 24.05.(Sa) 20:46:13  <txwikinger> Dies bedeutet, KDE Fehler sollten im KDE Bugtracker berichtet werden, OpenOffice in OpenOffice, Firefox in Mozilla usw.
2008 24.05.(Sa) 20:46:24  <txwikinger> Dies macht grundsätzlich immer Sinn wenn der Fehler klar in dem bestimmten Bereich ist.
2008 24.05.(Sa) 20:46:41  <txwikinger> Auf der anderen Seite gibt es aber Fehler, die nur in einer bestimmten Distro auftreten, oder auf die Interaktion zwischen verschiedenen unabhängigen Softwarepaketen beruhen.
2008 24.05.(Sa) 20:47:04  <txwikinger> Da ist es besser Launchpad zu benutzen, da man hier das Problem mehreren Paketen gleichzeitig zuordnen kann, und dann Tester und Entwickler die Möglichkeit gegeben wird während der Nachforschungen die Entscheidung zu treffen, wo die Lösung angesiedelt sein muss.
2008 24.05.(Sa) 20:47:20  <txwikinger> Auch das Neuzuordnung von Fehlerberichten von einem Paket zu einem anderen ist in Launchpad sehr einfach möglich.
2008 24.05.(Sa) 20:47:35  <txwikinger> s gibt auch Bestrebungen die verschiedenen Bugtracker mehr und mehr zu verbinden und als ein einzigen verteilten Bugtracker zu sehen.
2008 24.05.(Sa) 20:47:38  <txwikinger> Es
2008 24.05.(Sa) 20:47:51  <txwikinger> Dies ist eines der Ziele von Launchpad.
2008 24.05.(Sa) 20:48:03  <txwikinger> In der Zukunft, wird es möglich sein Fehlerberichte automatisch anderen Bugtrackern zuzuleiten, während Statusänderung weiterhin überwacht werden (so wie dies heute schon passiert).
2008 24.05.(Sa) 20:48:18  <txwikinger> Unter diesem Grundsatz sollten also Fehlerberichte in Launchpad erstellt werden, auch wenn dies im Moment manuelle Weiterleitung bdeutet.
2008 24.05.(Sa) 20:49:14  <txwikinger> Ich hoffe dies gibt die eine oder andere Anregung für zukünftige Fehlerberichte und ich stehe noch für Fragen zur Verfügung
2008 24.05.(Sa) 20:49:48  <dee> txwikinger: danke schonmal. :)
2008 24.05.(Sa) 20:50:07  <txwikinger> dee: Keine Ursache
2008 24.05.(Sa) 20:50:29  <PTS> txwikinger: Danke, sehr interessant.
2008 24.05.(Sa) 20:51:44  <txwikinger> Ok.. ich werde dann um 20:00 mit meinen Vortrag über Bug-Triage weitermachen
2008 24.05.(Sa) 20:51:51  <axel_> !
2008 24.05.(Sa) 20:52:03  <dee> Mit oder ohne Zeitmaschine, txwikinger? ;)
2008 24.05.(Sa) 20:52:16  <txwikinger> ok.. 21:00 :D
2008 24.05.(Sa) 20:52:23  <txwikinger> Ich bin in einer anderen Zeitzone